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This paper proposes a thought experiment to search for ef- 
ficient bounded algorithms of NPC problems by machine 
enumeration. The key contributions are: 

• On Universal Turing Machines, a program's time com- 
plexity should be characterized as: execution time(n) 
= loading time(n) + running time(n). 

• Introduces the concept of bounded algorithms; pro- 
poses a comparison based criterion to decide if a bounded 
algorithm is inefficient; and establishes the length up- 
per bound of efficient bounded programs. 

• Introduces the growth rate characteristic function to 
evaluate program complexity, which is more easily ma- 
chine checkable based on observations. 

• Raises the theoretical question: if there exists any 
bounded algorithm with polynomial execution time for 
NPC problems. 

Categories and Subject Descriptors 

C.1.3 [COMPUTATION BY ABSTRACT DEVICES]: 

Complexity Measures and Classes 

General Terms 

Algorithms, Experimentation, Measurement, Theory 

Keywords 

P ?= NP, program complexity, UTM 

1. MOTIVATION 

It has been for decades since the P ?= NP question was in- 
troduced by 01, but people still have not found a polynomial 
algorithm to any of the NPC problems. This leads many re- 
searchers to doubt if such algorithms exist at all. One way to 
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either confirm or dismiss the doubt is to exhaustively search 
for such algorithms. But this is impossible because in theory 
there are infinite number of programs, since usually we do 
not limit a program's length. 

However, let us consider a NPC problem with a partic- 
ular input size n. Suppose one of its solution program's 
length is in the order of exponential of n, in practice on 
a general-purpose computer (UTM), we will not consider 
such program efficient, since its loading time alone will take 
exponential time, regardless of the program's running time 
complexity. And for a specialized computer (TM), expo- 
nential length means the machine is too expensive to build, 
either from physical material, or virtual ones such as digital 
bits. This means there should a upper bound of the length 
of the program (with respect to the input size) that we will 
consider efficient. Given such program length upper bound, 
then the total number of programs is finite, so we can enu- 
merate them, and check if there exists an efficient program 
for a NPC problem. This is the main intuition that moti- 
vated this paper. 

This paper is organized as follows. In section 2, we discuss 
program complexity on Universal Turing Machines; in 2.1, 
we introduce the concept of bounded algorithms; in 2.2, we 
propose a comparison based criterion to decide if a bounded 
algorithm is inefficient; and in 2.3, we establish the length 
upper bound of efficient bounded algorithms. In section 3, 
we introduce a new way to evaluate program complexity, 
which is more easily machine checkable based on observa- 
tions. In section 4, we propose a thought experiment to 
search for efficient bounded algorithms of NPC problems 
by machine enumeration. In section 5, we raise the question 
whether there exists bounded algorithm with polynomial ex- 
ecution time for NPC problems, and discuss some possible 
implementation issues with the thought experiment. 

In this paper, when we talk about time complexity, it 
always means worst time complexity; and we sometimes use 
the term "algorithm" and "program" (that implements the 
algorithm) interchangeably. 

2. PROGRAM COMPLEXITY ON UNIVER- 
SAL TURING MACHINES 

Traditionally in theoretic computer science literature, an 
algorithm's time complexity quantifies the algorithm's run- 
ning time. It does not care about the algorithm's loading 
time. The reason is that when discussing time complexity, 
the computation model used is Turing Machine (TM, either 
deterministic or non-deterministic), which computes a fixed 
partial computable function (the algorithm). The machine 



description is pre-built, therefore there is no loading time, 
or we treat it always as 0. 

However, most of the computers people use today are the 
general-purpose computers. They are modeled on Universal 
Turing Machines (UTM), which first reads (loads) an arbi- 
trary stored-program, i.e. the description of a TM (algo- 
rithm), and then simulates it on arbitrary input. Therefore: 

Axiom On a UTM, for input size n, let the program's total 
execution time be E(n), loading time be L(n), and 
running time be R(n), then 

E(n) = L(n) + R{n) 

Theorem On UTM, if there exists an algorithm that solves 
a NPC problem in polynomial execution time, then 
both its loading time and running time should be poly- 
nomial. 

From now on, when we discuss a program's execution time 
complexity on a UTM, we also need to investigate the pro- 
gram's loading time. It is natural to assume that, for theo- 
retical UTMs (and practical general-purpose computers): 

Axiom A program's loading time is linear to the program's 
length. 

In computer science textbook, most algorithm's length is 
constant, and can handle all input size [0, +00). As the 
input size n increases big enough, the running time R(n) 
(normally a monotonically increasing function) will domi- 
nate the equation, so L(n) can be ignored. 

However on real world computers, programs can only deal 
with problems with input of finite size, because of either 
space (memory or disk) or time constraints. When the n is 
not big enough, or when an algorithm's length bears some 
relationship with the input size n, then L(n) cannot be ig- 
nored. 

As an example, in the following we will construct a pro- 
gram called PRECOMPUTE: it is a polynomial running 
time algorithm for the 3-coloring problem of undirected n- 
nodes graphs (a NPC problem) with input size [0, n] for some 
fixed n, but its loading time is exponential to n. First we de- 
fine program SIMPLE which will be used later to construct 
PRECOMPUTE. 

Example: SIMPLE Generate all the possible combinations 
of nodes 3-coloring schemes, then try them one by one 
to see if there is any conflicts, i.e. two adjacent nodes 
have the same color: 



# input : graph as the set of nodes & edges 
def SIMPLE Cg-{nodes , edges}): 

colorings = gener at e _all _ combinat ions C nodes , [R , 
for c in colorings: 

if no.conflict (edges , c): 
return true 
return false 



The running time of SIMPLE is exponential (i.e. 0(3"), 
where n is the number of nodes). Now let us construct 
PRECOMPUTE: 

Example: PRECOMPUTE Label each graph node with 
a unique number: {0, l,...,n — 1}, denote the edge 
between two nodes x and y as e^ XiV ), where x < y. 
There are \E\ = "xfo -1 ) possible edges between any 
two nodes, and there are \G\ = 2 |E| possible graphs 
with n nodes (we do not consider graph iso-morphism) . 



Label each possible edge with a unique prime number, 
i.e. h(e( x>y )) — piwherei G [0, |£7| — 1] and pi is the i-th 
prime number. Now each of the possible graph g G G 
can be uniquely labeled with a number by taking the 
products of all its edge labels: h(g) = T\ e eg M e )- I n 
computer science terms, the h we have just defined is 
the hash function of a graph. 

Now let us construct the program PRECOMPUTE: 
for each of the possible graph g G G, using SIMPLE to 
calculate if it can be 3-colored, and record the result 
as a pair (h(g),r) into a hashtable, where r is true or 
false depending on whether g can be 3-colored or not. 
Output the hashtable as the data segment of PRE- 
COMPUTE. 

The code segment of PRECOMPUTE is: for input 
graph g, 
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# input : graph as the set of nodes & e 


dge s 


2 


def PRECOMPUTE (g={nodes , edges }) : 
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hashtable = [. . . ( pre - c omput ed static 


data ) . . . J 
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if nodes . length > n: # check input 


size 


5 


return undef ined 
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else 
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key = h(g) 




8 


r = hashtable [key] 




9 


return r 





Line 7: calculate key — h(g), which takes at most 
0(\edges(g)\), i.e. time linear to the number of input 
edges 

Line 8: look up the result (true or false) from the 
hashtable using key, which takes O(l) time 

So the running time of PRECOMPUTE is clearly poly- 
nomial, while its loading time is exponential to \E\. 

2.1 Bounded algorithm 

The program PRECOMPUTE we have just constructed 
is different from usual programs in that it can only handle 
input upto a fixed size. Now let us introduce the concept of 
bounded algorithm. 

Definition: bounded algorithm given a number n, if an 
algorithm A returns correct result for any input of size 
< n; and returns either correct result or undefined 
for input size > n, then we say A is an n-bounded al- 
gorithm; if algorithm A always (theoretically) returns 
correct result for all input size [0, +00), then we say 
algorithm A is unbounded. 

The set of unbounded algorithms is clearly a proper subset 
of the set of bounded algorithms. In the real world com- 
puters can only work on problems of finite size, bounded 
algorithms will actually give programmers more design and 
implementation choices. 

Most algorithms in computer science literature are un- 
bounded, e.g. Euclid's CCD algorithm, and any sorting al- 
gorithms; and their length are constant (with respect to the 
input size n). So even on UTM, an unbounded algorithm's 
loading time can be ignored as n becomes significantly large 
enough: 

E(n) = R(n) 

For bounded algorithm, the algorithm's length can be re- 
lated to the input size, thus play an important role in the 
execution time complexity, just as we have shown in PRE- 
COMPUTE. 



Example: Search Engine It is also tempting to load a 
program once, and run it multiple times, so the execu- 
tion time equation becomes: 

E(n) = L(n) + m x R(n) 

And when m —5- oo, L(n) can be ignored. E.g. in 
such case, the PRECOMPUTE we just constructed 
becomes a search engine for the graph 3-coloring prob- 
lem, whose running time (query response time) as ap- 
peared to the user is polynomial. 

Since we have constructed an algorithm PRECOMPUTE 
with this property, we will not discuss such use case any 
more. In the remaining of this paper, we will only consider 
bounded algorithms with m = 1. 

2.2 A comparison based criterion to decide if 
a bounded algorithm is inefficient 

In the program PRECOMPUTE, by the way it is con- 
structed, we know that its length is exponential to the input 
size L{n) = 0(2' B '), so we can decide it is inefficient. Now 
suppose we do not know how this program is constructed 
(e.g. imaging it is from an oracle), and we lack necessary 
tools to analyze the relationship between its length and the 
input size. Then, what criterion we should use to decide 
that this program is inefficient for input size n? 

In the following, we introduce a comparison based crite- 
rion: 

Definition: UTM-inefHcient For a particular problem with 
input size n, on a fixed UTM, let knownjinef ficients 
be the finite set of all the bounded programs that hu- 
man know so far (by some other means, e.g. source 
code analysis) are inefficient. 

Let wet(prog(n)) be the worst execution time of pro- 
gram prog with input size n, and we denote the mini- 
mum of the worst-case execution time of all those pro- 
grams in knownjinef ficients as minwet(n) , i.e. 

minwet(known-inef ficients, n) 

minp r0 g£f ;:nown _i ne ffi C i en t s (wet(prog(n))) 

Let A be a n-bounded algorithm, if A's execution time 
is longer than any known inefficient algorithm, i.e. 
E(A, n) > minwet(known_inef ficients, n) then A is 
called UTM-inefficient for the given input size n. 

For example, initially we can add SIMPLE, and PRECOM- 
PUTE to the knowledge base knownjinef ficients: 

• SIMPLE, length complexity O(l), running time com- 
plexity 0(3 |nodes| ). 

• PRECOMPUTE, length complexity 0(2 |E| ), running 
time complexity 0(\edges\). 

Note, as the human knowledge {knownjinef ficients) in- 
creases, minwet(n) will decrease. 

2.3 Length upper bound of efficient bounded 
programs 

Corollary If a n-bounded algorithm's length > minwet(n) , 
then it is UTM-inefficient. 
Proof. E — L + R, and L > minwet(n), therefore E > 
minwet(n). □ 

Thus minwet(n) is an upper bound of the length of efficient 
bounded programs. 



3. A COMPUTABLE PROPERTY OF PRO- 
GRAM COMPLEXITY 

Let us exam the execution time complexity on UTM again: 

E{n) = L(n) + R(n) 

We have established the length upper bound of efficient 
bounded programs, before we can start to enumerate pro- 
grams on a UTM, and search for efficient bounded programs 
for NPC problems, there is one more issue: it will be better 
to have a method to evaluate an algorithm's running time 
that is machine checkable. 

Traditionally, the running time complexity of an algorithm 
is analyzed by human. We take the algorithm's description 
(e.g. source code), and use human knowledge and skills to 
establish a mathematical model and formulate a limiting 
function of the program's running time with respect to its 
input size. However this step cannot be easily formalized 
and automated by a computer program. In the this section 
we will introduce a method to evaluate program complexity 
that is more machine checkable based on observations. 

Definition: growth rate characteristic function let f(n) 
be the limiting function of the complexity of an al- 
gorithm with input size n in the big-0 notation, i.e. 
T(n) = 0(/(n)), for n > 1 we define 

ff (/(n))=log„/(n) 

as the growth rate characteristic function of the algo- 
rithm. 

Note, it does not matter whether it is time complexity T(n), 
space complexity S(n), or any other kind of program com- 
plexities, the following discussion apply to all of them. 

Let us consider two important limiting functions in al- 
gorithm complexity analysis: polynomial and exponential 
functions, let k > be constant: 

• For polynomial complexity T(n) = 0(n k ), g(f(n)) = k 

k 

• For exponential complexity T(n) = 0(2 n ), g{f(n)) = 
n k log n 2 

3.1 Apply g on observations 

Given a program, we can record its actual running steps 
corresponding to a series of input size [no, ni, ...n,] as our 
observations. We will study <?'s properties on these observa- 
tions. Let ob(n) be the actual observed steps for the algo- 
rithm performed on input of size n: 

• For polynomial complexity T(n) — 0{n k ): by the def- 
inition of big-O notation, there exists constant M > 0, 
such that ofc(n) < M x n k , where n > no for some 
constant no > 1, then 

g{ob{n)) = log n ob(n) 

< log n M x n 

= log n M + log n n fe 

= log n M + k 

and 

lim g(ob(n)) < lim (log„ M + k) = k 

Summary: the upper bound of g(ob(n)) has limit k; 
and it is monotonia decreasing with max value (log 2 M+ 



k) if M > 1, or monotonic increasing with min value 
(log 2 M + k) if M < 1. 

For exponential complexity T(n) = 0(2" ): 
g(ob(n)) = log n o6(n) 

< log n M x 2" fc 

= log„Af + log n 2" fc 

= log„ M + n k log n 2 

and 

lim ff(o6(n)) < lim (log n M + n k log n 2) 

n — >- + oo n^ + oc 



n— > + oo 



lim n log n 2 
n fe In 2 



lim 

n-n-oo Inn 



(L'Hopital'srule) 
kn k ~ 1 ln2 



lim 

n— > + oo 



1/n 



lim fcn In 2 

n — ► -poo 
= +00 

Summary: the upper bound of g(ob(n)) has limit +oo; 
and it is monotonic increasing after sufficient large rfl- 

Example The following two figures illustrate the upper bound 
function curves for polynomial and exponential com- 
plexity: 



polynomial: g(A/ x 
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Note: what we just discussed is the bounding function's 
property of an algorithm, which is different from the actual 
observations. For example, the g of actual observations of 
a polynomial algorithm can be oscillating, but still being 
bounded, e.g. a program that blankly loops for n 2 + cos ( n ^) 
steps for input size of n. 

3.2 gi e on finite observations 

Since we can only make finite observations, any algorithm's 
g will always be bounded by some value. For example both 
the algorithms in the previous example are bounded by g = 5 
for observations on input of size [2 — 16]. Because of the 
"sufficient large n" assumption, we are more interested in 
the ending point metric. Let us introduce a notation g^J 1 '^ 
where n e is the ending observation point n, and u is the max 
value of g(n) for all n £ [2, n e ], for simplification we use its 
ceiling integer value, i.e. 

u(n e ) = ceiling(max n £[2,n e ](g(n))) 

So in the previous example, the polynomial is a gf 6 algo- 
rithm, while the exponential is a g\ 6 algorithm. 

Algorithm efficiency evaluation method: Given an al- 
gorithm A, if for all sufficiently large observation points 
n < m, u(rn) < u(n), then A is a possible polynomial 
algorithm. 

4. A THOUGHT EXPERIMENT TO SEARCH 

FOR EFFICIENT iV-BOUNDED ALGORITHMS 
OF NPC PROBLEMS BY MACHINE ENU- 
MERATION 

In the previous sections, we have established the length 
upper bound UB of efficient bounded algorithms on UTM. 
Now we can start exhaustive searching for efficient bounded 
algorithms of NPC problems by machine enumeration. The 
basic idea is that, for input size n, first generate all the 
possible programs of length less than UB, and also generate 
all the program input of size upto n; then for each program, 
feed all the inputs into it, and run the program prog for upto 
UB — prog.length steps, if it returns all correct answers on 
those inputs, then add the program to output list. 

Finally we output all the correct n-bounded algorithms 
(sorted with the smallest g^™' value of the worst running 
time at first) for further analysis or human inspection, e.g. 
using machine aided extrapolation to check if there is any 
efficient unbounded algorithms. 

4.1 Search by enumeration 

Let us continue to use the 3-coloring problem. The above 
description can be formalized by the following algorithm: 



1 The proof is left as an exercise to the interested readers. 



known. inef f icients - {SIMPLE, PRECOMPUTE } 
while True : 

UB = minwe t C known_inef f i c i ent s , n) 

outputs = [] 

for length in [1 , UB J : 

programs = gener at e _pr ograms^f rom_ s tr ings _wi th C length ) 
for prog in programs: 
results = [] 
label : input_loop 

for size in [1, n]: 

prog . worst _running_t ime [size] = 
inputs = gener at e _all _ input s _with C size ) 
for input in inputs: 

max^steps = UB - prog.length 

(result, ac t ual_s t eps ) = run (prog, input, max_steps) 
results. append (result , (size,actual_steps)) 
if not ( re suit . correct ) : 

break input.loop 
if actual_steps > prog . wor st _running_t ime [ size ] : 



prog . wor st _running_t ime [size] = actual.steps 
if allCresults correct): 
out puts . appendCprog) 
sort C output s, by(u(n))) 
want _ improve = analyze ( outputs ) 
if want^improve : 

updat e_knowle dge_base ( known_inef f i c i ent s ) 1 
else : 2 
return output s 3 
| 4 

5 

Line 1, seed the set knownjinef ficients with two known ^ 
inefficient programs SIMPLE, and PRECOMPUTE. s 

Line 3, set the initial upper bound U B. 10 

Line 5-7, enumerate all the programs with length up to H 
UB. H 

Line 8-13, For each of the program prog, feed all the inputs 
of size [l..n] one by one. 17 

Line 15, for each input, run the program upto (UB — 
prog .length) steps. 

Line 16, record the pair (result, (n, step(n))). 

Line 21-22, if all the returned results are correct, then 
record prog 

Line 23-24, output the findings for further analysis, or 
human inspection. 

Line 25-28, if we want to search further, update the pro- 
gram knowledge base known_inef ficients , and continue the 
next search iteration. 

4.1.1 Update program knowledge base 

The outputs from the previous step may contain bounded 
programs that are running time efficient, but loading time 
inefficient, for example, there may be a program that has 
the same running time but half the length of PRECOM- 
PUTE, and whose length still holds the exponential rela- 
tionship with input size n. We need to analyze such pro- 
grams by human, and if it is found to be inefficient, we 
add it to the program knowledge base knownAnef ficients. 
This will lower the program length upper bound UB = 
minwet(known_inef ficients , n); we will re-run the enumer- 
ation process after such knowledge base update. Fortu- 
nately, as the total number of outputs is finite, this knowl- 
edge base updating process will stop when the knowledge 
base become saturated. 

4.1.2 Expand search horizon 

Also during the search process, there may be programs 
that have big constant loading time, but polynomial run- 
ning time for [no, +00) for no > n, which we will skip. How- 
ever, this is not a real limitation of our approach, as we keep 
increasing n to expand our search horizon, these programs 
will be examined again at that time. With the computing 
resource increases and implementation improves, the search- 
able n will keep increasing, and we will gain more knowledge 
about bounded algorithms. 

4.2 Machine aided extrapolation 

There are many interesting things can be done to check 
the output program's various properties. Probably the most 
interesting are: 

1. whether any output is actually a potential unbounded 
algorithm, and 

2. whether its running time complexity is polynomial. 

We can perform these two tests with the help from com- 
puter: given the output of bounded algorithms, we can feed 



bigger inputs into them, and check if they will continue re- 
turn correct results. This can be formalized by the following 
algorithm: 

def analyze C programs , n) : 
m = 2 * n 

UB = minwe t C known. inef f i c i ent s , m) 
for prog in programs : 
results = [] 
label : input_loop 

for size in [n+1 , m] : 

inputs = gener at e .all .input s.wi t h C s ize ) 
for input in inputs: 

max. steps = UB - prog . length 

result = runCprog, input, max. steps) 

results . append (result ) 

if result = undefined: # i.e. bounded 
break input. loop 
if allCresults correct): 

prog . pot ent i al .unbounded = true 
if uCm) <= uCn): 

prog . pot ent i al _ef f i c i ent = true 
candidates = f i It er C programs , by C pot ent i al .unbounded ) ) 
return human. inspe ct (sort (candidates , by ( po t ent i al _ef f i c i ent ) 

Line 1-11, for each output program prog, continue feed all 
the problem input size of [n + l,m], (e.g. set m = 2 x n), 
and run it for upto UB — prog. length steps 

Line 13-14, if prog return undefined, prog is a bounded 
bounded algorithm, we can just skip it 

Line 15-16, if prog continue return all correct results, then 
mark prog as a potential unbounded algorithm 

Line 17-21, if the growth rate characteristic function of 
the running time of program prog continues to appear to be 
efficient, then prog is a potential efficient unbounded algo- 
rithm. We give prog high priority for human inspection. 

If it is proved to be unbounded efficient, then prog is the 
program that can solve NP problem in P time. The author 
of this paper believes that we will not find such an algorithm, 
but would be very happy to see a pleasant surprise. 

5. DISCUSSIONS 

5.1 Does there exist any bounded algorithm 
with polynomial execution time for NPC 
problems? 

This paper has proposed a thought experiment to search 
for efficient bounded algorithms of NPC problems by ma- 
chine enumeration, however the author is more interested 
in knowing, and hence would like to raise the theoretical 
question: 

Problem 1. Does there exist any bounded algorithm with 
polynomial execution time for NPC problems? 

Although this question is weaker than the original P ?= NP 
question, it has the same importance in practice. After all 
in this real world we human only have limited resource to 
build such programs if they exist. 

Compare with the original P ?= NP question, can we 
take advantage of the extra program length constraint, and 
develop some new techniques to find a proof? 

5.2 Connections to speedup theorems and al- 
gorithmic information theory 

In computational complexity theory, the linear speedup 
theorem for Turing machines states that for any TM solv- 
ing a problem with t(n) running time, and for any c > 0, we 
can build an equivalent TM' that can solve the same prob- 
lem with ct(n) + n + 2 running time. If we take a closer look 
of the proof of this theorem (e.g. in ch-2.4), and check 
how the new TM' is constructed, we will see that the run- 
ning time speed up is achieved at the expense of increased 



machine length (i.e. program length). Blum's speedup the- 
orem [l| works the same way by adding "short-cuts" to the 
TM's control table also using the precompute technique. 
However running time speedup does not always mean in- 
creased program length. We can achieve both shorter pro- 
gram length and faster running speed at the same time by 
using the precompute-and-cache technique, e.g. finding the 
number of 3-colorable graphs with n-nodes. 

In algorithmic information theory, the Kolmogorov com- 
plexity [J of a string (a program in our case) is defined as 
the length of the shortest program that can generate the 
string; while this paper tries to connect a program's length 
(the information / knowledge formally encoded in it) with 
its running time efficiency. 

5.3 Possible implementation considerations 

In practice we have programs with length of many thou- 
sands or millions of bytes, it will take prohibitively expensive 
resource to enumerate them, so the idea proposed in this pa- 
per is more a thought experiment. But if we can start work 
on small input size, and develop techniques to reduce the 
search space. E.g. if we can decide: there is no efficient 
bounded program of 3-coloring problem for input size of 4, 
5, 6. etc. Then before we can find a solution to the P/NP 
problem, we will gain some knowledge as the exploration 
length increases. There are many areas can be developed 
to speed up and improve the enumeration and evaluation 
process, for example: 

• Choose a Universal Turing Machine and a NPC prob- 
lem with appropriate properties to reduce the enumer- 
ation time or space requirements. 

• Develop techniques to reduce the number of programs 
we need to search. For example let us consider all the 
possible 64-bit long strings, which correspond to 2 64 
Turing Machines (i.e. programs), probably most of 
them do not specify valid programs or will abort when 
being executed. We can skip generating such invalid 
program strings from the beginning. 

• Develop other machine checkable criterion to decide a 
generated program's length and time complexity. 
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